The information exchanged between two MIDI devices is musical in nature. MIDI information informs a music synthesizer, in a most basic mode, when to start and stop playing a specific note. Other information includes the volume and modulation of the note, if any. MIDI information can also be more hardware specific. It can inform a synthesizer to change sounds, master volume, modulation devices, and how to receive information. In more advanced uses, MIDI information can be used to indicate the starting and stopping points of a song or the metric position within a song. More recent applications include using the interface between computers and synthesizers to edit and store sound information for the synthesizer on the computer.
The basis for MIDI communication is the byte, and each MIDI command has a specific byte sequence. The first byte of the MIDI command is the status byte, which informs the MIDI device of the function to perform. Encoded in the status byte is the MIDI channel. MIDI operates on 16 different channels, numbered 0 through 15. MIDI units will accept or ignore a status byte depending on what channel the unit is set to receive. Only the status byte has the MIDI channel number encoded, and all other bytes are assumed to be on the channel indicated by the status byte until another status byte is received.
As is shown in greater detail in the following Table, some of the functions indicated in the status byte are Note On, Note Off, System Exclusive (SysEx) and Patch Change. Depending on the status byte, a number of different byte patterns can follow. The Note On status byte tells the MIDI device to begin sounding a note. Two additional bytes are required, a pitch byte, which tells the MIDI device which note to play, and a velocity byte, which tells the device how loud to play the note. Even though not all MIDI devices recognize the velocity byte, it is still required to complete the Note On transmission.
Reference can be made to the Complete MIDI 1.0 Detailed Specification, MMA 1995, for further details on the structure and operation of MIDI (available at www.midi.org/about-midi/specinfo.htm).
The command to stop playing a note is not part of the Note On command; but is instead a separate Note Off command. This command also requires two additional bytes with the same functions as the Note On command. The Patch Change byte requires only one additional byte that corresponds to the program number on the synthesizer. The patch number information is different for each synthesizer.
The SysEx status byte can be used to initiate a number of functions. Briefly, the SysEx byte requires at least three additional bytes. The first is a manufacturer's ID number or timing byte, the second is a data format or function byte, and the third is generally an “end of transmission” (EOX) byte.
TABLEStatusData Byte(s)D7-D0D7-D0DescriptionChannel Voice Messages1000cccc0nnnnnnnNote Off event. This message is sent when0vvvvvvva note is released (ended).(nnnnnnn) is thenote number. (vvvvvvv) is the velocity.1001cccc0nnnnnnnNote On event. This message is sent when0vvvvvvva note is depressed (start). (nnnnnnn) isthe note number.1010cccc0nnnnnnnPolyphonic Key Pressure (Aftertouch).0vvvvvvvThis message is sent when the pressure(velocity) of a previously triggered notechanges. (nnnnnnn) is the note number.(vvvvvvv) is the new velocity.1011cccc0nnnnnnnControl Change. This message is sent0vvvvvvvwhen a controller value changes.Controllers include devices such as pedalsand levers. Certain controller numbers arereserved for specific purposes (seeChannel Mode Messages) (ccccccc) is thecontroller number. (vvvvvvv) is the newvalue.1100cccc0pppppppProgram Change. This message is sentwhen the patch number changes.(ppppppp) is the new program number.1101nnnn0cccccccChannel Pressure (After-touch). Thismessage is sent when the channel pressurechanges. Certain velocity-sensingkeyboards do not support polyphonicafter-touch. This message can be used tosend the single greatest velocity (of all thecurrent depressed keys). (ccccccc) is thechannel number.1110nnnn01111111Pitch Wheel Change. This message is sent0mmmmmmmto indicate a change in the pitch wheel.The pitch wheel is measured by a fourteenbit value. Center (no pitch change) is2000H. Sensitivity is a function of thetransmitter. (111111) are the least significant7 bits. (mmmmmm) are the mostsignificant 7 bits.Channel Mode Messages (See also Control Change, above)1011nnnn0cccccccNote that for the Channel Mode Messages0vvvvvvvthe same code as the Control Change(above) is used, but Mode control isimplemented by using reserved controllernumbers. The numbers are:Local Control: When Local Control is Off,all devices on a given channel willrespond only to data received over MIDI.Played data, etc. is ignored. Local ControlOn restores the functions of the normalcontrollers. c = 122, v = 0: Local ControlOff c = 122, v = 127: Local Control OnAll Notes Off: When an All Notes Off isreceived, all oscillators will turn off. c =123, v = 0: All Notes Off c = 124, v = 0:Omni Mode Off c = 125, v = 0: OmniMode On. c = 126, v = M: Mono Mode On(Poly Off) where M is the number ofchannels (Omni Off) or 0 (Omni On) c =127, v = 0: Poly Mode On (Mono Off)(Note: These four messages also cause AllNotes Off)System Common Messages111100000iiiiiiiSystem Exclusive. This message covers0ddddddd . . .unsupported MIDI features. (iiiiiii) is a0dddddddseven bit Manufacturer's I.D. code. If the11110111synthesizer recognizes the I.D. code as itsown, it will listen to the rest of themessage (ddddddd). Otherwise, themessage will be ignored. SystemExclusive is used to send bulk dumps suchas patch parameters and other non-specificdata. (Note: Real-Time messages onlymay be interleaved with a SystemExclusive.)11110001Undefined.111100100lllllllSong Position Pointer. This is an internal0mmmmmmm14 bit register that holds the number ofMIDI beats (1 beat = six MIDI clocks)since the start of a song. 1 is the LSB, mthe MSB.111100110sssssssSong Select. The Song Select specifieswhich sequence or song is to be played.11110100Undefined.11110101Undefined.11110110Tune Request. Upon receiving a TuneRequest, all analog synthesizers tune theiroscillators.11110111End of Exclusive. Used to terminate aSystem Exclusive dump (see above).System Real-Time Messages11111000Timing Clock. Sent 24 times per quarternote when synchronization is required.11111001Undefined.11111010Start. Start the current sequence playing.(This message will be followed withTiming Clocks).11111011Continue. Continue at the point thesequence was Stopped.11111100Stop. Stop the current sequence.11111101Undefined.11111110Active Sensing. Use of this message isoptional. When initially sent, the receiverwill expect to receive another ActiveSensing message each 300 ms (max), or itwill be assumed that the connection hasbeen terminated. At termination, thereceiver turns off all voices and returns tonormal (non-active sensing) operation.11111111Reset. Reset all receivers in the system topower-up status.
While well suited for its originally intended applications, it has been found that MIDI is not particularly well suited for use in a wireless communications environment or, more generally, when transmission through a lossy, error-prone transmission channel is required. However, it would be desirable to provide wireless users with entertaining audio applications, such as one that could be referred to as group playing, that would require streaming MIDI connectivity between mobile terminals. Unfortunately, the integration of radio transmission technologies and MIDI has not proven to be robust when using conventional methods.
Modem mobile systems provide radio transmission technologies such as Bluetooth (low power, short range RF communications) that enable applications in different devices to easily communicate with each other. An important requirement for data transmission is the reliability, while latency is not a critical feature, whereas for speech transmission a short latency and a constant jitter variance are the most important parameters, while the reliability is typically not as critical.
However, a short latency (interactivity), small jitter variance and high reliability are all important and desirable features for MIDI transmission. These requirements can be contradictory when over-the-air transmission is used, especially when the quality of the radio channel is low. When the channel quality degrades the error rate increases, causing the effective transmission bandwidth to decrease. If an unreliable transmission protocol is being used then MIDI messages can be corrupted or lost, which is normally unacceptable. On the other hand, if a reliable transmission protocol is being used the latency will tend to increase because of re-transmissions that may render useless a time critical musical communication.
As was made apparent above, MIDI messages represent symbolic data. A given MIDI message can be independent from other messages, or it can have a relationship to other messages. Because of this relationship between MIDI messages, message corruption or loss during transmission is not acceptable. Examples of very critical related MIDI events are the Note On and the corresponding Note Off messages. If a Note Off message is missing after a corresponding Note On message, the result can be a note to be played for an unacceptably long period of time (i.e., a “hanging” note).
A Network Musical Performance (NMP) occurs when a group of musicians, located at different physical locations, interact over a network to perform as they would if located in the same room. In this environment the significance of a lost Note Off message has been recognized, as evidenced in a publication entitled “A Case for Network Musical Performance”, J. Lazzaro and J. Wawrzynek, NOSSDAV'01, Jun. 25-26, 2001, Port Jefferson, N.Y., USA. These authors describe the use of a client/server architecture employing the IETF Real Time Protocol (RTP) to exchange audio streams by packet transmissions over a network. An RTP packet in the MIDI packetization scheme described by these authors is shown in FIG. 3, and includes a standard RTP header, including a sequence number and a timestamp, followed by a packet payload that contains a MIDI Command payload and a Recovery Journal. The Recovery Journal contains information that enables the receiver to recover from the loss of all RTP packets sent since an earlier RTP packet, referred to as a checkpoint packet. Appendix 1 of this publication describes the format of the Recovery Journal.
Related to this publication is another publication: “The MIDI Wire Protocol Packetization (MWPP)”, also by J. Lazzaro and J. Wawrzynek, http://www.ietf.org/internet-drafts/draft-ietf-avt-mwpp-midi-rtp-02.txt, Internet Draft, Feb. 28, 2002 (expires Aug. 28, 2002).
The requirement to include the Recovery Journal in the packet payload can be a disadvantage when used in a bandwidth-constrained link, such as a wireless link. Further, the maintenance of the Recovery Journal can add to the overall system complexity.